home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000090_owner-urn-ietf _Fri Mar 28 21:37:39 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  5KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id VAA07487
  3.     for urn-ietf-out; Fri, 28 Mar 1997 21:37:39 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id VAA07481
  6.     for <urn-ietf@services.bunyip.com>; Fri, 28 Mar 1997 21:37:35 -0500 (EST)
  7. Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA19935  (mail destined for urn-ietf@services.bunyip.com); Fri, 28 Mar 97 21:37:30 -0500
  9. Received: from localhost (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) with SMTP id VAA13316; Fri, 28 Mar 1997 21:37:29 -0500
  10. X-Authentication-Warning: beethoven.bunyip.com: leslie owned process doing -bs
  11. Date: Fri, 28 Mar 1997 21:37:28 -0500 (EST)
  12. From: Leslie Daigle <leslie@Bunyip.Com>
  13. To: Dan Connolly <connolly@w3.org>
  14. Cc: "Karen R. Sollins" <sollins@LCS.MIT.EDU>, urn-ietf@bunyip.com
  15. Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
  16. In-Reply-To: <333C317A.1BD455E5@w3.org>
  17. Message-Id: <Pine.SUN.3.95.970328212322.13282G-100000@beethoven.bunyip.com>
  18. Mime-Version: 1.0
  19. Content-Type: TEXT/PLAIN; charset=US-ASCII
  20. Sender: owner-urn-ietf@Bunyip.Com
  21. Precedence: bulk
  22. Reply-To: Leslie Daigle <leslie@Bunyip.Com>
  23. Errors-To: owner-urn-ietf@Bunyip.Com
  24.  
  25. One thing I want to flag...
  26.  
  27. On Fri, 28 Mar 1997, Dan Connolly wrote:
  28. > Karen R. Sollins wrote:
  29. > >  Hence there is a certain burden of
  30. > > proof on the proposer of an identification (URN) namespace that does
  31. > > not hold true for a location (URL) namespace.
  32. > 
  33. > Hmm... OK, if there are some process rules that we believe
  34. > will result in more persistent, reliable names, then it's
  35. > worth writing them down.
  36. > 
  37. > I think it's a contractual issue, and not worth specifying in
  38. > a technical sense. But that's just my intuition, and in the
  39. > case of process, the relevant question is whether the participants
  40. > of the IETF are willing to standardize some contractual
  41. > properites. It seems that you/they/we are, so away we go...
  42.  
  43. True, it's not technical in the sense that it won't affect code.  But,
  44. it _is_ an important component of the technical architecture in that it
  45. is also a statement of what we think this system can and cannot support.
  46. I.e., we will give persistent, unique, global names as long as input
  47. meets X, Y, and Z criteria.
  48.  
  49. > 
  50. >     URN:ISBN:4534-345-345
  51. > 
  52. > which syntactically binds the name to the URN process contract,
  53. > it seems sufficient to write
  54. > 
  55. >     ISBN:23423-234-234
  56. > 
  57. > and have the ISBN scheme specification say "this scheme
  58. > conforms to the URN process contract."
  59.  
  60. This issue was specifically brought up at the meeting in San Jose, and
  61. was documented in the minutes.   See
  62.  
  63.     http://www.bunyip.com/research/ietf/urn-ietf/sanjose.txt
  64.  
  65. (by the way -- http://www.bunyip.com/research/ietf/urn-ietf  also
  66. contains the text of the group's charter).
  67.  
  68. Specifically, there were people who said they _needed_ the syntactic
  69. cue for their purposes  of using URNs, and no one who said they could
  70. not deal with it.
  71.  
  72. Some of the desire for having the syntactic cue are for resolution
  73. reasons (e.g., being able to hand that _class_ of identifiers to a specific
  74. proxy that knows about existing RDS's), and some are for weighting
  75. clues (e.g., prefer URNs to URLs).  _Yes_, you could keep a table fo which
  76. identifier was which type, but that's an implementation answer, and does
  77. not seem to be what general concensus said people wanted.
  78.  
  79.  
  80. > If not, please somebody explain why not, and write it
  81. > up in a spec, and let's review it.
  82.  
  83.  
  84. It has been discussed ad nauseum, and was put to bed with the syntax
  85. document following the San Jose meeting.  If you have an idea of a specific
  86. paragraph that belongs in a specific document, do _please_ make the
  87. suggestion to the list.
  88.  
  89. If you think there is more to be discussed here about the issue, I will
  90. ask you to first forward your agruments to me, and if there is new material
  91. we can take the discussion to the list.
  92.  
  93. Thanks!
  94. Leslie.
  95.  
  96.  
  97. ----------------------------------------------------------------------------
  98.  
  99.   "_Be_                                           Leslie Daigle
  100.              where  you                           
  101.                           _are_."                 Bunyip Information Systems
  102.                                                   (514) 875-8611
  103.                       -- ThinkingCat              leslie@bunyip.com
  104. ----------------------------------------------------------------------------
  105.